INTRODUCTION:

The significance of Computer System Validation (CSV) in ensuring patient safety, data integrity, and regulatory compliance is emphasized in this article. In order to encourage quality and system reliability in pharmaceutical operations, it emphasizes the significance of adhering to standards such as GAMP 5 and 21 CFR Part 11, implementing risk-based validation models, and resolving frequent FDA-cited issues through proactive planning and documentation.

CSV uses a structured approach for confirming and validate that systems are appropriate for their intended use, covering the full system lifecycle from planning and design to operation and retirement. FDA leaders Ted Byers and Bud Loftus originally introduced the idea of validation in the pharmaceutical industry in 1979. Their aim was to raise the standard of pharmaceuticals, particularly in consideration of problems with the sterility of parenteral drugs used in large quantities. At first, production procedures, machinery, and environmental controls were the focus of validation efforts.

Validating computerized systems became necessary as the pharmaceutical industry began to incorporate them into manufacturing and quality control procedures. The FDA published the "Blue Book," also referred to as the "Guide to Inspection of Computerized Systems in Pharmaceutical Processing," in 1983. The first official framework for computerized system validation in pharmaceutical circumstances was offered by this handbook^1,2.

· 21 CFR Part 11, which established standards for electronic records and electronic signatures, was issued by the FDA in 1997. For the purpose of to ensure data integrity and compliance to Good Manufacturing Practices (GMP), the legislation required that computer systems used in regulated environments undergo validation.

· In 2002, the FDA released the "General Principles of Software Validation," which emphasized the significance of a systematic approach for ensuring software compliance and reliability and provided comprehensive guidelines on software validation procedures^{3,16,17,19,20,21,24}.

History of GAMP :

For the aim of validating computers in pharmaceutical manufacturing, GAMP provides a set of guidelines. Pharmaceutical industry and manufacturers in the UK initiated the GAMP initiative in 1991 to address the lack of defined procedures for computerized system validation. It was created by the International Society for Pharmaceutical Engineering (ISPE) to provide a systematic approach to ensure that computerized systems adhere to Good Manufacturing Practice (GMP) guidelines. With an emphasis on defining roles, responsibilities, and documentation requirements for systems validation, the prior versions of GAMP (1–4) developed progressively. These successive iterations prioritized Supplier Assessment, Lifecycle Documentation, and Testing Procedures and established the basis for categorizing software systems.

The widely used GAMP 4 (2001) version incorporated software categories based on complexity (e.g., operating systems, configurable software, and customized software), maintained a heavy emphasis on vendor assessment and documentation.

A major conceptual change from previous versions, GAMP 5 introduced a risk-based approach to validation when it was released in February of 2008. "GAMP 5: “A Risk-Based Approach to Compliant GxP Computerized Systems" is the full title.

GAMP 5 supports compliance with:

· EU Annex 11

· ICH Q9 (Quality Risk Management)

· ICH Q10 (Pharmaceutical Quality System)

· 21 CFR Part 11 (FDA)

GAMP 5 Second Edition (2022) of Released in July 2022, it updates and clarifies:

· Integration with modern technologies (cloud computing, SaaS).

· Agile methodologies and automation testing.

· Cybersecurity and data integrity.

FDA expectations for CSV in pharma^18,23,24.

"As per FDA expectations, the following seven points must be fulfilled to ensure compliance in any pharmaceutical industry setting: Compliance with 21 CFR Part 11, Risk-Based Approach (as per GAMP 5), Lifecycle Approach to Validation, Documentation and Audit Readiness, Data Integrity Compliance (ALCOA+), Periodic Review, Change Control, Training and Defined Roles."

Compliance with 21 CFR Part 11:

Electronic signatures and electronic records are covered under this rule. Systems must generate secure, computer-generated, time-stamped audit trails, according to FDA standards. Electronic signatures are identical to handwritten signatures, have their own unique characteristics and can be verified. The objective of access control is to stop illegal use. Systems, including a backup, recovery, and archiving, ensure data integrity.

Risk-Based Approach (as per GAMP 5):

FDA promotes a risk-based validation approach and focus more validation effort on high-risk systems.

Lifecycle Approach to Validation:

Validation should cover the entire system lifecycle, including Planning, Requirements, Design and Development, Testing Deployment and Operation and Retirement.

Documentation and Audit Readiness:

The FDA expects Validation Master Plan (VMP) outlining scope, methodology, and deliverables. Complete and controlled documents: URS, FS, IQ/OQ/PQ protocols, Traceability Matrix, Test Results, Deviation Reports, etc. Systems must always be audit-ready with thorough document traceability.

Data Integrity Compliance (ALCOA+):

Data Integrity Compliance under ALCOA+ is primarily governed by the U.S. FDA’s 21 CFR Part 11 and also supported by predicate rules like 21 CFR Part 210, 211, and 820, depending on the product type.

Data should be Attributable, Legible, Contemporaneous, Original, and Accurate. Additional expectations: Complete, Consistent, Enduring, and Available. Controls over data entry, change control, audit trails, and system security are key FDA inspection points.

Periodic Review and Change Control:

The FDA expects systems to be reviewed periodically to ensure they remain in a validated state. Change-controlled any software updates, configuration changes, or infrastructure modifications must be assessed, documented, and validated.

Training and Roles:

Validation team members and users must be trained in CSV, system use, SOPs, and regulatory requirements.

Training records should be retained and reviewed during audits.

Why is CSV performed in the pharmaceutical industry?

Regulatory Compliance:

Computerized systems that manage GxP data (such as those related to manufacturing, quality control, or patient’s safety) must be validated by agencies like the FDA, EMA, and MHRA. Systems used to produce, modify, preserve, or distribute electronic records or signatures must be validated in accordance with 21 CFR Part 11.

Data Integrity and Accuracy:

Ensures the accuracy, consistency, and completeness of electronic records over the lifespan of the data lifecycle. Protects patient safety and product quality by preventing data loss, alteration, or corruption.

Product Quality Assurance:

Validated systems reduce the risk of errors in product development, manufacturing, and testing.

Risk Mitigation:

Identifies potential system failures or user errors before they impact operations.

Audit and Inspection Readiness:

Traceable documentation and audit trails are maintained by a confirmed system, which is essential to both internal and regulatory audits. Demonstrates that the company continues to be responsible for all its computerized systems.

Operational Efficiency:

A validated system encourages consistent procedures, minimizes downtime, and enhances reliability. This reduces cost overruns, improves output, and helps in the process of digitization.

Electronic Records and Signatures:

Validation ensures that electronic systems are secure, valid, and traceable by ensuring that they meet the requirements for electronic signatures (ES) and electronic records (ER).

Software classification as GAMP 5:

The Good Automated Manufacturing Practice (GAMP) 5 framework classifies computerized systems into five categories based on their complexity and degree of customization. This classification guides validation strategies^1,3,10.

GAMP Category 1:

Infrastructure software provides the platform or environment for other software systems. It does not directly perform GxP functions but supports them.

Examples: Operating Systems (Windows, Linux), Database Management Systems (Oracle, SQL Server), Network software, middleware

Approach: Validation focuses on installation qualification (IQ) and operational qualification (OQ) of the infrastructure and ensuring proper maintenance. Since the software itself is developed by vendors and not modified, the emphasis is on controlling the environment.

GAMP Category 2: Firmware (Less commonly used now) Software embedded in hardware that cannot be easily modified.

Examples: Embedded controllers, device firmware

Approach: Testing of hardware-software integration and ensuring proper functioning. Typically validated as part of the hardware qualification.

GAMP Category 3: Non-configured Products/Standard software products used without configuration or customization. No changes to source code or settings that alter functionality.

Examples: Microsoft Word, Excel Statistical analysis tools (e.g., JMP, Minitab)

Approach: Focus on installation qualification (IQ), operational qualification (OQ), and ensuring proper use per SOPs. Vendor documentation and quality certifications are reviewed. Risk is generally low.

GAMP Category 4: Configured Products Software products that can be configured by the user to meet specific requirements, but without custom coding.

Examples: Laboratory Information Management Systems (LIMS), Manufacturing Execution Systems (MES)

ERP systems with configurable modules.

Approach: User requirements must be clearly defined. Validation includes verifying correct configuration (IQ/OQ/PQ). Configuration documentation and traceability of requirements to tests are critical. Vendor support and functional testing of configurations are essential.

GAMP Category 5: Custom Applications Custom-developed software applications or heavily customized commercial software where source code is modified.

Examples: In-house developed software and Custom modules developed for existing platforms.

Approach: Full software development lifecycle (SDLC) applies, including requirements specification, design, coding, testing (unit, integration, system, user acceptance), and thorough documentation. Validation is rigorous due to higher risk.

Validation models:^2,4,7

V-Model (Traditional CSV Lifecycle Model):

The V-Model represents a linear, sequential validation lifecycle where each development phase corresponds to a matching testing phase. It’s the most widely accepted model in pharmaceutical validation. Justification for Use Preferred by regulatory auditors and each test maps directly to a requirement. The V-Model is a validation lifecycle model that maps the relationship between each phase of the system development lifecycle (SDLC) and its corresponding testing or verification activity. It is shaped like the letter “V” to depict the descending development stages on the left and ascending testing/validation stages on the right.

It is the foundation of GAMP 5 guidance and is extensively used in regulatory compliance activities, such as those required under FDA 21 CFR Part 11, EU Annex 11, and MHRA data integrity guidance^11,12.

Agile Validation (Risk-Based + Iterative):

Agile is an iterative, incremental development methodology. CSV in Agile aligns with the CSA (Computer Software Assurance) approach from the FDA (2022 draft), emphasizing critical thinking, product quality, and less documentation. Agile validation is a modern substitute for the traditional V-model lifecycle in computerized system validation, particularly in cloud-based and challenging circumstances. While conforming to GxP standards, 21 CFR Part 11, and GAMP 5, it integrates the principles of agile software development with regulatory validation requirements, allowing incremental validation and continuously delivered software.

Agile, compared to the V-model, emphasizes flexibility, user input, and iterative testing, making it perfect for systems undergoing continuous improvement^5,6,7,8.

Essential Steps in Computer System Validation:

Validation Planning: Define the scope, objectives, responsibilities, deliverables, and schedule of the validation effort. Develop a Validation Master Plan (VMP) or Validation Plan document. Define acceptance criteria, regulatory requirements, and standards to be met. Identify roles and responsibilities.

Perform an initial Risk Assessment to prioritize validation efforts^1,9,15,22.

User Requirements Specification (URS):

Document what the system must do from the user perspective. Define functional, performance, security, and compliance requirements. Requirements must be clear, measurable, and testable. Include interfaces, data handling, audit trails, electronic signatures if applicable.

Risk Assessment:

Identify assess and mitigate the risks of system malfunction or failure. Evaluate the impact on data integrity, patient safety, and product quality. Enhance the range and depth of validation testing with risk. Risk assessment techniques include FMEA, FTA, HACCP, or others.

Supplier/Vendor Assessment:

Evaluate the quality and compliance of software/hardware suppliers. Review vendor quality systems, software development lifecycle, and validation documentation. Assess vendor audits and certifications.

Functional Specification (FS)/Design Specification:

Detail how the system will meet the URS. Describe system functionality, data flow, interfaces, security controls.

Installation Qualification (IQ):

Verify that the system and its components are installed correctly in the intended environment.

Verify installation according to vendor documentation and confirm system environment (network, OS, database) meets specifications.

Operational Qualification (OQ):

Verify that the system operates according to functional specifications under defined operating conditions.

Execute tests for each functional requirement and Test boundary conditions, error handling, and security functions. Document test results and resolve discrepancies.

Performance Qualification (PQ):

Confirm the system performs as intended in the actual production environment. Test the system using real data and normal operating conditions. Include end-user acceptance testing.

Testing and Test Documentation:

Demonstrate that the system meets user requirements. Develop and approve test protocols and scripts aligned with URS. Execute tests and document results, including deviations. Maintain traceability matrix linking tests to requirements.

Change Control:

Manage changes to the system post-validation to maintain compliance. Evaluate impact of changes on validated state. Revalidate affected functions, as necessary. Maintain records of changes, approvals, and testing.

Training:

Ensure personnel understand system operation and compliance requirements. Develop training materials based on validated system procedures. Conduct and document training sessions.

Backup, Recovery and Data Integrity:

Protect critical data from loss and ensure system resilience. Define backup and recovery procedures. Test backup and restoration. Implement controls to maintain data integrity.

Periodic Review and Maintenance:

Ensure ongoing compliance and system performance throughout lifecycle. Conduct periodic system reviews. Monitor for deviations or failures.

21 CFR part 11 FDA Regulation on Electronic Records and Electronic Signatures:

Title 21 of the Code of Federal Regulations (CFR) Part 11 is a regulation issued by the U.S. Food and Drug Administration (FDA) that defines the criteria under which electronic records and electronic signatures are considered trustworthy, reliable, and equivalent to paper records and handwritten signatures in FDA-regulated industries^18,23.

Electronic Records:

Systems must ensure record integrity and authenticity. Records must be accurately maintained, secure, and readily retrievable. Audit trails must be implemented to track changes and ensure traceability. Records must be protected against alteration or deletion.

Electronic Signatures:

Electronic signatures are legally binding and equivalent to handwritten signatures. Must be uniquely linked to a single individual. Systems must ensure signatures cannot be forged or repudiated.

Signature components include:

Printed name of signer, Date/time of signing and meaning of the signature (e.g., approval, review)

System Validation:

Computer systems managing electronic records must be validated to ensure accuracy, reliability, consistent performance, and the ability to detect invalid or altered records.

Audit Trails:

Secure, computer-generated, time-stamped audit trails must track record creation, modification, and deletion. Audit trails should be retained and available for review.

Security Controls:

Access controls must be in place to limit system access to authorized individuals. Passwords, biometrics, or other secure methods must be used to identify users.

Common risk Factors, Compliance Impacts, and Mitigation Strategies related to CSV^1,10,13

Summary of Risk Factors, Compliance Impacts, and Mitigation Approaches in CSV.

Sr No.	Risk / Factor	Problem Description	Impact on CSV and Compliance	Mitigation Strategy
1.	Insufficient or Poorly Defined Requirements	User Requirements Specifications (URS) or functional requirements are vague, incomplete, or missing.	Difficult to design test cases or verify system functionality; scope creep; inadequate validation coverage.	Conduct thorough requirements gathering. Review and approve all URS documents before starting validation activities.
2.	Lack of Risk-Based Approach	Validation effort is not based on the risk impact of system components or functions.	Wasted resources on low-risk systems; critical functionality may be under-tested.	Apply risk assessment tools (e.g., FMEA, HACCP) early in the lifecycle to prioritize validation efforts.
3.	Inadequate Vendor Assessment	Supplier’s development processes and validation documentation are not reviewed or audited.	Potential for non-compliant or unreliable software; increased project delays.	Perform vendor qualification through audits, questionnaires, and review of certifications (e.g., ISO 9001, GAMP).
4.	Poor Change Control	Changes to configuration, software, or environment are not tracked or evaluated.	Loss of validated state; risk of system failure and regulatory violations.	Implement structured change control with documented impact analysis and revalidation where necessary.
5.	Inadequate Testing and Documentation	Test protocols are incomplete, poorly executed, or not traceable to requirements.	Critical defects may go undetected; insufficient validation evidence for audits.	Develop risk-based, requirement-driven test plans. Ensure full documentation of test results and deviations.
6.	Lack of Traceability	Requirements are not clearly linked to specifications and tests.	Unable to demonstrate requirement coverage; audit and compliance failures.	Maintain traceability matrix linking URS → FS/DS → Test Cases → Results. Review it regularly.
7.	Inadequate Training	Users and validation team are unfamiliar with system usage or validation procedures.	Incorrect use of the system; non-compliant documentation or testing.	Provide documented, role-specific training before and after validation. Maintain training records.
8.	Data Integrity Issues	Weak controls over data entry, audit trails, access, or backup.	Data loss, manipulation, or non-compliance with 21 CFR Part 11 / Annex 11.	Implement data integrity controls: audit trails, access restrictions, backup validation, and monitoring.
9.	Incomplete or Missing Documentation	Validation plans, protocols, or reports are missing or not finalized.	Gaps in validation evidence; regulatory non-compliance.	Use document control procedures; conduct periodic documentation audits.
10.	Overlooking Operational Environment	Network, hardware, and environmental compatibility are not validated.	Performance issues or failures during system operation.	Conduct Installation Qualification (IQ) and interface testing to verify compatibility and readiness.
11.	Poor Project Management	No clear assignment of roles, communication plan, or timeline.	Delays, miscommunication, inconsistent quality in validation deliverables.	Assign a project manager, define roles and responsibilities, and hold regular project review meetings.
12.	Inadequate Periodic Review and Maintenance	Systems are not reviewed or maintained after validation.	System may drift from its validated state; security or functionality issues arise.	Establish periodic system review schedules. Include triggers for revalidation after changes or upgrades

CSV Observations and Preventive Strategies to Ensure Regulatory Compliance.

Sr No.	Lack	Observation	Avoidance
1.	Validation Documentation	Missing, incomplete, or poorly maintained validation documentation (e.g., validation plans, test protocols, test reports).	Maintain complete and up-to-date validation documentation. Use document control to ensure versioning and approvals. Ensure traceability between requirements, tests, and results.
2.	Lack of Formal Risk Assessment	No evidence of risk assessment guiding the scope and depth of validation.	Perform and document formal risk assessments early in the validation lifecycle. Use risk to prioritize critical system functions and validation efforts.
3.	Inadequate Change Control	Changes to validated systems not controlled, assessed, or revalidated appropriately.	Implement a robust change control process. Assess impacts of changes on validated state and revalidate if necessary.
4.	Insufficient Testing	Test protocols lack adequate coverage or do not demonstrate that requirements are met.	Develop comprehensive test scripts covering all user requirements and functional specs. Document test execution and resolution of deviations.
5.	Poor User Requirements Definition	User requirements are vague, incomplete, or missing.	Ensure URS is complete, clear, testable, and approved before validation starts.
6.	Lack of Traceability	Inability to trace user requirements through design, implementation, and testing.	Maintain a traceability matrix linking URS, specifications, and test cases.
7.	Failure to Validate System Security and Access Controls	Inadequate controls for user access, passwords, and electronic signatures.	Validate security features and user access controls. Implement strong authentication and audit trails
8.	Inadequate Audit Trails	Missing or incomplete audit trail functionality or failure to review audit trails.	Implement and validate audit trail features. Establish procedures to review and maintain audit trails regularly.
9.	Improper Backup and Recovery Procedures	Lack of tested backup and data recovery procedures.	Develop, validate, and regularly test backup and disaster recovery processes.
10.	Lack of Training Documentation	No evidence of adequate training for personnel on validated systems.	Train users and validation teams on system operation and compliance requirements. Maintain training records.
11.	Failure to Conduct Periodic Reviews	No evidence of ongoing system monitoring or periodic validation reviews.	Establish periodic review programs to assess system performance and compliance.
12.	Inadequate Vendor/Supplier Controls	Failure to assess and qualify vendors supplying software or services.	Perform supplier audits and review vendor quality documentation.

CONCLUSION:

Computer System Validation (CSV) is essential for ensuring compliance, data integrity, and patient safety in the pharmaceutical industry. By following standards like GAMP 5 and 21 CFR Part 11, companies can validate systems effectively and reduce regulatory risks. Adopting structured, risk-based validation approaches such as the V-Model or Agile model system reliability. Addressing common CSV challenges and FDA observations through proactive planning and documentation further strengthens compliance. Ultimately, CSV is not just about meeting regulations it ensures trust and quality in critical computerized processes.

CONFLICT OF INTEREST:

The authors declare no other conflicts of interest and affirm that the content reflects independent research and interpretation.

ACKNOWLEDGMENTS:

The authors sincerely thank Alfa Biomed India Private Limited, Pune, and the Department of Quality Assurance for their valuable support and access to regulatory resources. Special thanks to Mr. Pawankumar Bawadankar and the Rajwada Boys for their continued support during the preparation of this manuscript.

REFERENCES:

1. Singh A, Sharma P, Gupta R. Computerized system validation in pharma. J Drug Deliv Ther. 2018; 8(S6): 359–65. doi:10.22270/jddt. v8i6-s.2102

2. Katre M, Deshpande R, Patil S. Review on regulatory aspects of CSV in pharma. Int J Pharm Sci. 2024; 2(7): 1012–9. doi:10.5281/zenodo.12739502

3. Raja JR, Sinha V, Mehta T. Quality assurance through computer validation: A review. J Pharm Qual Assur. 2024. doi:10.7759/cureus.67555

4. Rusjan B. Quality systems and compliance risks in GxP environments. J Contemp Manag Issues. 2020; 25(2): 1–23. Available from: https://hrcak.srce.hr/247329

5. The Manufacturing Chemist. The right validation model: practical considerations and applications. Manuf Chemist. 2021.

6. Walia G, Neri D. Computer software assurance and critical thinking. Pharm Eng. 2024 Mar/Apr. Available from: https://ispe.org/pharmaceutical-engineering/march-april-2024/computer-software-assurance-and-critical-thinking

7. Food and Drug Law Institute advancing the transition to computer software assurance. FDLI J. 2023. Available from: https://www.fdli.org/2023/05/advancing-the-transition-to-computer-software-assurance

8. Uzzaman S. Computer systems validation: a systems engineering approach. Pharm Eng. 2003; 23(3): 1–10.

9. Yogesh P, Kumari D, Thakur R. Validation of computerized systems in pharmaceuticals. World J Pharm Res. 2015; 4(9): 444–54.

10. Bhaskar R, Bawadankar P, Bijawe A, Nilwarn S. Review on computer system validation in pharma industry. Int J Pharm Res Appl. 2023; 8: 1759–64.

11. Savitha S, Kathiresan K. Review on regulatory guidelines for CSV. Int J Biol Pharm Allied Sci. 2022; 11(11): 5257–67. doi:10.31032/IJBPAS/2022/11.11.6567

12. Dhatchanamoorthi N, Kamaraj R. Validation of computerized systems: A regulatory approach. Res J Pharm Technol. 2020; 13(11): 5591–4. doi:10.5958/0974-360X.2020.00975.0

13. Hesham AM, Patan IK. A review on software validation requirements in pharma. Open Access J Pharm Res. 2020; 4(4): 000219. doi:10.23880/oajpr-16000219

14. Weichel P. 4 FDA observations that can be avoided with good CSV practices. J Valid Technol. Available from: https://blog.montrium.com/experts/4-fda-observations-that-can-be-avoided-with-good-csv-practices

15. Bjarnason E, Wnuk K, Regnell B. Aligning requirements with VandV: A literature review. Software Eng Rev. 2023.

16. ISPE. GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems. Tampa, FL: International Society for Pharmaceutical Engineering; 2008.

17. ISPE. GAMP 5 Guide: A Risk-Based Approach to Compliant GxP Computerized Systems. 2nd ed. Tampa, FL: ISPE; 2022.

18. U.S. Food and Drug Administration. 21 CFR Part 11 – Electronic Records; Electronic Signatures. Washington, DC: FDA; 1997.

19. International Council for Harmonisation (ICH). ICH Q9: Quality Risk Management. Geneva: ICH; 2005.

20. International Council for Harmonisation (ICH). ICH Q10: Pharmaceutical Quality System. Geneva: ICH; 2008.

21. European Commission. EudraLex - Volume 4 - GMP Guidelines – Annex 11: Computerised Systems. Brussels: European Medicines Agency; 2011.

22. U.S. Food and Drug Administration. General Principles of Software Validation; Final Guidance for Industry and FDA Staff. Rockville, MD: FDA; 2002.

23. U.S. Food and Drug Administration. 21 CFR Part 11: Electronic Records; Electronic Signatures. Available from: https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?CFRPart=11

24. ISPE GAMP® Community of Practice. GAMP® 5 FAQs and Updates. 2022. Available from: https://ispe.org

25. Montrium. 4 FDA observations that can be avoided with good CSV practices. Available from: https://blog.montrium.com/experts/4-fda-observations-that-can-be-avoided-with-good-csv-practices

26. Part11Solutions. FDA warning letters for CSV failures. Available from: https://part11solutions.com/fda-warning-letters/

Received on 18.06.2025 Revised on 19.07.2025

Accepted on 11.08.2025 Published on 04.10.2025

Available online from October 10, 2025

Asian J. Res. Pharm. Sci. 2025; 15(4):388-394.

DOI: 10.52711/2231-5659.2025.00057

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. Creative Commons License.

Company and Year	Key FDA Observations	Related CSV Failures
Ranbaxy (2008	Falsified data, audit trail manipulation.	Inadequate audit trails and insufficient testing.
Emcure (2016)	Missing audit trails and weak data controls.	Inadequate Audit trails, security, access control and test documentation.
Hebei Yuxing (2016)	Poor documentation and contamination handling.	Validation documentation, change control, and backup procedures.
Industry Trend (2010–2020)	High data integrity and system validation citations	Entire CSV risk framework documentation, traceability and controls.

Summary of Risk Factors, Compliance Impacts, and Mitigation Approaches in CSV.

Examples of FDA Findings Related to Audit Trails, Data Integrity, and CSV Failures.

CSV Observations and Preventive Strategies to Ensure Regulatory Compliance.